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FTP AND NETWORK MAIL SYSTEM Revd (SMAR7S 


This paper describes my undersStanaging of tne results of the 
Network Mail System meeting SRI-ARC on February 23, 1973, and tie 
implications for FTP (File Transfer protocol). There was general 
agreement at the meeting that network nail function should be wWitnin 
FTP. 


FTP currently rerevides two commands for handling mail, The WAIL 
command allows 2 user to send mail Via the TELNET conection (the server 
collects the mail ami determines its erà by searecningeg for the cnaractar 
Sequence "CHKLF.CHLF"). The MLFL (mail file) command allows a user to 
Send miil via the data connection (requires a user=FTP to banale tne 
Command burt treasrer is more efficzrent 25 server need not searcn ror a 
Special character seruene). These commands are being used to erevics 
Network mailing facilities. Local mail and SHIMSG programs have been 
modified at many sites to incluce network mailing (e.g, USERSHOsT at 
BBN-YENEX and MAIL nest user at MIT-DMGG). 


The network mail systen snould provide a facility whereby users can 
conveniently sena meztSeres to other network users who nave "maiipooxes” 
at one or more hosts. It is not required that the messages or mail ce 

alivered in reai-tine. The network mail systena is not an interactive 
anter-console communication facility, but it may be possible for sara 
Sites to deliver "urgent" mail to users in real=tinme (e.g., print marl 
at user console if user is currently lozzed-in). The mail System alsə 
does not provice a general inter~process communication facility, tneuch 
it may be possible to deliver messages vO programs whicn have mailccx 
addresses, Inter-process and inter-entity communication facilities ire 
Very desirable put are vceyond the scope of the network mail Syster. 


The concepts of "mailbox" and "mailbox addresses" are central to 
this aiscussicn of network mail system. A Mailrox is a place wnere tie 
the mail is stored before a user nicks it upe It may be a file ain wis 
user's directory or it nay be a bin for hard=copy. The mailbox 
address is the address required by tne sender in order to send tne nail 
to its destination mailocx. For users who have an "on-line" networs 
Mailbox, tne mailbox address contains the Host address and the user's 
Mailbox identification at that Sost. The mailhox identification 15 
that whicn is reyuireu by an FTP<-server in order that it may put the 
Mail in the desired nailbox. The terms mailbox address and address 
Will be used to rerer to the online network maialocx aadresse 


NETWORK MAIL SYSTEM FUNCTIONS 


Tne network mail system should provide the, following 
six functions: : 


, CREATING: This refers to the manner in which the user creates or 
omposes his message. The FTP servers do not explicitly provide any 
message euiting capability (Server's eaiting conventions may be 
applicable in tne case or MAIL command). Editing conventions sucn 
as tnose for character delete and line cancel vary Widely over tne 
Network, The User is most familiar with his local Host conventions 
and these should be usea for network mail eaiting. Tne user also nas 
access to locai editing systens which can pe used for conposing Message 
files. The message file may then ce transmitted via the MAIL or »iL i 
commanus (HLFL being preferable). Tne present FTP approach of assuming 
the creation of messezes tO pe sender's respensibility seems adequate. 
TIP users if they desire editing facilities should use intermegiate 
Hosts for creating and sending meSSazes, 


2. LOCATING: How sentier determines receivers address. FTP assumes 

that tne sender Kncews the receivers correct address. There is ne 

Ppublisred or “one-line” list of mailbox addresses. There is, however, 

a list of netwerk participants meintained (on-line) and pubiisned oy 

the Network InZzormation Center (NIC) at SRITARC. The network users 

-have been assigned a unique "NIC Ident" and Host site by the Nic. 

It was therefore specified in FTP that FTF-Servers maintain a taole 

that maps NIC Idents to mail-box iaentifications. Tne NIC will msintain 

On=line and publish tne local majilsox address information for networkd 

Participants. It would be possible ror users to look up a publisnea 
ist, or querry the NIC on-line to locate destination addresses. 

tne NIC will also provide an on*line facility (Similar to FTP) thet can 

be used by programs for retrieving the address information. ‘This latter 

approach of the NIC's maintaining addresses has several advantages. 

The user can ottain a nurber of addresses for a group, and use trese 

to transmit nail., The FTP servers need rot ñaintain NIC Ident Taoles, 

and the NIC can provide a good facility for locating addresses rron 

last nanes, NIC idents, or even sxetcny information, It may Still ce 

desirable tnat FTP servers accept NIC adents, last names, and ovner 

Standard forms as mailbox identifiers, 


3. SENDING: How message is sent to the destination mailbox, The 
messages may be sent directly to tne destination nailbox (vila TELNET 
Or Data connections) or via an intermediate Host such as the NICe 

FTP does not explicitly provide for mail forwarding by intermediate 
Hosts out FIP Servers may be aole to recognize addresses as not velns 
local, and forward mail. In tne event mail ıs to pe forwarded, a 
deSirable facility is to Nave the intermediate site return an 
acknowledgnent (by request) upon delivery of mail or if delivery ‘ails 
within a specified tine. The current FTP specifications recommenda 
that FIrP-servers accept multiple addresses but ao not require this. 


he STORING: Where mail is stored before reading and if information 
is available for later reference or retrieval. Tne FTP does nov 
require that sender store mail or keep duplicate copies, It 18 
tne receiver's responsibility to store the information for reading, 
sference, or retrieval. The receiver need not store the mail 
28 a data file but can directly print it out on a user console or 
line printer. FTP does not specify the vrocedures for storage nancling 
py intermediave sites. If intermediate site is used for forwaraing 
the mail then it snould be the responsibility of that site to store 
mail until it is delivered to its final destination. If the maıl 
is undeliverasle then the intermediate site should return the 
undelivered infcrmation to the sender, A Similar situation arises 
when sending of mail is deferred py the Sending site (destination 
host may ve down). The sending site tnen acts as an intermediate 
forwarder insofar as the user 15 concerned. 


S. RECORDING: Should the mail be catalogued and recorded for later 
reference and retrieval, FTP currently aoeces not provide an 
explicit mechanism ror the receiver to record mail. If an 
intermediate site (tne NIC) is used for mail distripution ther 
a function of such a site could be to record mail, if so requested. 
NIC is iaceal fer recording mail, but other sites may also wish 
to record mail. If the mail is recorded, then 1t is not necessary 
to send the entire contents of the nail. Instead only a citation 
for the decument can ne sent and the receiver can retrieve tne 
Mail only if he wants to, This is Particularly useful tor large 
documents such as NWG/PFC Which are distriouted to a group, The 
itation may contain autnor, title, retrieval pathname, and 
pernaps an abstract. 


6. READING: How the mail is finally presented to and read by the 
user. FTP currently assumes that mail reauinzg is entirely tne 
receiving site's function. However, there are ways in which the 
Senaer can aid tne receiver in providing improved mail reading 
facilities, Fer example, tne receiving system, if it Knows a 
message to be urgent can aeliver it immediately at a user console, 
Long messages may be put in separate files With notification in 
user's regular mail., Alternately, mail could ve a citation tnat tne 
Yeading progran can retrieve upon user reauest. Selective 
handling of different classes of mail is important for an improved 
network mail system. 


MODELS FOP MAIL SYSTEM USE 


The user of a mail syStem can use intermediate site for locating 
addresses, recording and/or districuting mail, and for creating 
and reading mail. We thererore have the following models for mail 
Systen use: 


l. The user connects directly to the destination FTP server and senas 
Mail using the MAIL command. Local editing functions are limited to 
Character delete and line cancel (assuming user is in line-wa-tine 
mode) and server conventions may also apply. The user only neeus a 

3ereTSLNET program at his site but needs to Know the destination 
.«d@ress, This nodel is specially applicable to TIP and other mini- 
Host users Whe do not have a user-FTP or user=Mail programs. 


2. The user composes tne mail using a local editor (or mail systen) 

and then requests his user-FTP or mail program to send the mail 

directly to the deStinavtvion via the FTP MAIL or MLFL commands. Tae user 
NneedS to know the destination address. The mail can be deferrec ty vne 
Sendinz program if the aeStination Hest is aewn. TIP users can use 

this model by using tne facilities of a "nome-base" Host. 


3. The user uses an intermedinte site such as NIC (other sites may 
provide forwarding services too) for mail distributicn. The user 
need not know tne destination addresses cut can use NIC idents for 
individuals and ecroups of individuals, Tne mail can be recorced on 
request ana its Sencine can ve deferred (the destination Host hey 

be aown, or it may be more economical to defer mail). Tne meSSaze Lo 
be mailed may te created at the local site using local editing 
facilities, or it may be created Girectly at the intermediate 

Site. 


he. The user may sena a citation of the mail instead of the complete 
ail item. Tne citation refers to an existing dccument which 

can be retrieved on-line (Such as the NIC nurber of a NIC journal 
communication). 


MAILING TO TIP USERS 

The TIP dces nov currently orovide an FTP server or mailbox 
facilities. while ut is possible to sénd mail to TIP terminals 
(such as line printers) it seems undesirable to do so because of 
the possibility of losing Mail, the lack of privacy, and the 
fact that user nay he Several (or Several huna@red) males away 
from the location of the TIP. The TIP users normally have a 
"home=case" computer Where tney do their computing work most of 
the tine. The TIP tser problemn is pest solved py requiring 
that TIP users rent nailboxes at their "home-oase" Host. Such 
a Host can provide gocd mall reading and querry faciiities. A 
TIP user can request his "hone" Host to Send hin notification 
Of mail on a TIP terminal. If RDML command (NWU/RFC 458) 
is accented in FTP, TI sera could use such a commana. More 
important, if the user has a number of nailroxes on different 
Hosts, the RDML (or 25@F) command can be used to read his mail 
at all the Sites Where he has mailboxes. 


ACCESS CONTROL IN MAIL laa. : . . l 
It has been sugpestea tnat FTP specification snould require 
that mail functicn (rer receiving nail) should ove "free", 1.€., 
TP Servers Should not require the user te "login" (Sena the USsk, «ASo, 
nd ACCT commands). In the absence of the access control conmanas 
the FTF server should cnarge the cast of receiving mail to an 
overnead or brcowsingZg account, It snould te noted that this "irec" 
Mail function using default "USER" account may not allow non 
Madlmrelated cOmMands Without reinitializing. This requirement bil. 
inprove communication amone the network users. 


Some systems, sucn aS MUlVicSsS, nave mechanisms tor access 
control in the receiot of Mail. That is a user can Specify who 
is eligicle to send nim mail (normally users give.the access 
"eH oe,e", 1266, any one can sena mail). The access central 
commands would be required to gain Privilegea access. The USER 
command aoes net seen the pest way to identify the sender of 
mail., Consider users logged in as GUEST, ICCC, NETWOKR, MIT=unNceG, 
and NETWOERK<“USER, A separate FPOM connand seems desirable, Sucn 
a ommand can be used to identify the senser as well as to send 
acknowledgnents ana replies. Tne receiving Site can tag the maıl 
as: FeAOM ALB at NIT-DUCG, logged in as GUEST, The receiver cana 
then send reply to the mailbox address AKR at Host 7O (SNDMSG 
AKBeDMCG or MAIL DhiCG Axks), , 


NETWORK INFORMATION CENTER FUNCTIONS 

The NIC as a very special facility for handling mail. It 
rovides facilities for recoraing ana Gistrilbuting mail to 
aundividuals ana grouns of individuals, and for locating users! 
addresses, The NIC will also unaertake to provide distribution 
of unrecorded rail. Currently the NIC reauires that users log 
into the NIC ard use NLS to create and distribute nall. Using 
NLS for creating mail has oeen a frustrating experience for many 
Who are used to dificrent eaitin® sysvenms, kecently there nas 
been a problem that NIC is overloaded at most tines of the day 
and even if one can get a "network terminal” and log in, tne > 
interaction is quite slow. As NIC (or NLS) is designed for 
Charactermaterartine interaction witn remote echo, the use is 
inefficient. Using N1C is particularly unbeeraole when the user 
falls behind in ais ecno by as mucn as an entire laine. 


An alternative to direct use of NIC is to use the NIC via FTP 
and prograns at the user's site, The user can create journal 
documents using his own local editing system and then transfer 
it to NIC via FTP, Tne user nay nave to specify such information 
as autnor, title, where the acknowledgment should be sent, and jJoursñal 
Number if tne item is to pe recorded. It snould also be passive 
for users to send sequential files to NIC and nave tnem restructures 
into NLS forn eee having to do an "input sequential" (a suggesvion 
is to "NLS" the file if its name is suffixed with a .NLS). Alternately 


it should be possiole for user's to retrieve journal documents and 
otner Sequential files without having to do a previous “output 
Sequential". 


The NIC curently delivers mail via hardcopy and/or on-line. 
On-line currently means that user must log into NIC to see if he 
has a messaze and read it by "print branch". Tne messages are not seen 
by the destination users for several days and many users get tneir 
hara copy before they have had a chance to examine their on-line NIC 
Mail. If the NIC were to deliver mail via FTP to network users, wtnen 
the mail turn-around time Will be greatly speeded ana the users wilu 
not have to lor into tne NIC., Large documents need not ce Maliec 
to the user in their entirety put only a citation need be sent. 
Tne NIC will nave te collect the inforration on the mailbox addresses 
of Network participants sor selivering nail, especially since it 
appears that many FTP servers are nov "respecting" NIC 1dents. 
It is recognized that a user may nave more than one Valid mailbox 
address, but the NIG needs to nave only one (tne most used) of unese 
addresses, 

The NIC identification subsystem (currently accessable via NLS 
Only) contains information on users (such aS affiliation, US Mail 
adress, telephone numoers, etc.) and proups (menbers, etc.). Tne 
Oneline mailbox address information can be addea here. The NIC 
Will ungdervake to provide a facility wnereby the identification 
Subsystem can ke querriea by prorrams, allowing mailing programs to 
retrieve tne addresses auitonatically. his facility will be Seperate 
from FTP. 


FTP MODIFICATIONS 

The FTP currently does not provide explicit facilitiies for 
recording nail, communicating sender's address, sending progran 
readable citations, sctecirfying autnor and title for aocunents, 
requesting acknowledzyments, and indicating message type (urgent, 
Ordinary, and dong). Yo cVercome these deficiencies, we can take 
any of the following approacnes: 


l. Kludge the desired features in the pathnzeme syntax of the MAIL 
and MLFL connands, justifying the kludge on the grounds that 
most of the functions are to te used only by the NIC. 


2. Add new commands for the desired functions and alter the 
MAIL and MLFL commands somewhat to recognize the existence 
of the new connmands, 


3e Define a new mail command which incorporates tne missing 
functions (in the process cefinine new commands for the aesired 
functions). The MAIL and MLFL commands can be used ın their 


present form but may be gradually phased out. 


The first aporoach seems undesirable to me as many of the 


wissing functions can ne used by other sites aS Well. In addition 


it 


Will be easier to write programs to deal with ceonmands ratner 


than a complex syntax. The Second and the tnird approaches 

are not very aifferent from eacn other, The tnird approach seens 
preferable as it Will allow existing mail programs to function in 
their present form, Using the third approach consider the following 
new FTP commands: s 


l, 


5. 


Te 


MLTO (mail to): Tne argument is one or more mailbox identifiers 
Separated oy "," (commas). It is suggested that if there 15 no 
areunent, the maal snould be sent to Sone responSible user or 
printed on a printer, Ihis comnand starts the Sequence of optional 
FTP mail related conmands aescrived below. The sequence ends 

Witn the TEXT, FILE, or CITA (citation) commanas. 


FRO“: The argument is the adaress of the sender or senders. It 

is in a standard form that can be interpreted by programs as weil 
aS human users. Tne information is to be used for identifying 

the sender(s), for sendinz replies, and for sending acKnowleagrneats 
if the receiver is an intermediate forwarding site. 


MTYP (mail tywc): This identifies the type of mail as U (urefent!, 
Q (ordinary), and L (long). The receiving? system can take ne 
appropriate actions from this knowledge. The default assuncvion 
is ordinary mail. 


Pa 


RECO (record the mail): The argument if present is the identifyin:; 
information for vecorcing (such as NIC Journal numoer). If no 
argument is present tne server will assign the recording infornation 


and send an appropriate reply (real-time or deferrea). 


AUTH (author): tdentifies the autnor of the document in a form 
acceptable to the server (NIC ident may be requiréd by NIC). 


TITL (title): laentifies the title of the document. The argument 
1S an ASCII string ending with the sequence "CKLF.SPLF", 


ACKN (acknowledge): Relevant for intermediate forwarding sites. 
ASKS the server to Send acknowledgment on delivery or if delivery 
fails within a specified time, 


8, TEXT: NO arguments, Starts the transrer of mail over TELNET 
connection in an identical manner as MAIL. . 


e FILE: No arfuments. Starts transfer of mail over the data connection 
in an identical manner as MLFL. 


10. CITA (citation): Argument is the pathname of a retrievable file. 


We also need to define new renly codes for nandling mail. sore 
Sites nave expressed the need fer reslices Such aS "Send only X ytes 
of mail", Other repiies could specifically request adaiticnal conmands 
Sucn aS USER/PASS/ACCT for Mnriviliced nailing, FRKOM/ACAN for mail 
forwardinz, and AUTH/TITL for recorded mail. Another sugzesvicon tnat 
May be given consideration is allowing TYPE/SYTE other than A/S for 
FILE commande Mailing large files between like Macnines sucn 
as PDP=-10s is more efficient in I/36. The RDML ana RDMF commands 
proposea by Bressler and Tanomas (NaG/RFC 158) also merit consideration 
as they would aid the handling of mail for users who have mailtoxes 
at different Hosts. 


